Design programs allow users to specify various designs such as text documents, web pages, spreadsheets, and illustrations. A common interface for modern design programs is a graphical design environment that allows users to specify the design at the same time as the design is displayed. This mode of design specification is commonly referred to as what-you-see-is-what-you-get (WYSIWYG). This mode of design specification assists the design process because a user is able to constantly preview the design as it is being specified. However, certain designs are too complicated to specify and preview in the same environment. This is particularly true for interactive graphical designs.
Interactive graphical designs, such as web sites, are problematic for graphical design environments because both the design itself and the design environment are interactive. With reference to web page design 100 in FIG. 1, clicking on button 101 for purposes of specifying the design could bring up a widget interface for specifying the characteristics of button 101; whereas clicking on button 101 while the design was being rendered could execute the rendering of a “submit” action in which the information entered in prompts 102 would be accepted and stored for later use by the design. As illustrated, it is difficult to provide both the interactivity of the design environment, and the interactivity of the design itself in a single interface. Furthermore, an instantiation of the design that provided both of these levels of interactivity would be heavily encumbered by its dual responsibility, and would be inefficient if used as a final design. As a result, interactive graphical designs are generally exported from their design environments for rendering in an external player. In the case of a web page, an example of an external player is a web browser used to render the web page design.
Although separating out the design specification and rendering of an interactive graphical design provides for a large advantage in terms of simplifying the design environment, separating the design environment from the rendering environment can make it difficult to figure out how the state of the design in its rendering environment relates back to the design as it was specified. Furthermore, when the design is exported from the design environment it is generally compiled into an encoding in a lower level language so it is difficult to understand how portions of the encoding relate back to this design. Both of these factors can make debugging the design difficult. If the interactive design crashes, or doesn't perform as expected while it is being rendered in a player, the designer will have to back-track to figure out what was wrong with how the design was specified by reloading the design in the design environment. This problem is exacerbated when the exported design is encoded in a lower level language before it is rendered. It is extremely difficult to translate up from a lower level language description of a design to glean a more cogent description of what the lower level language is describing. Therefore, there isn't a simple intermediate link between an aspect of the design as rendered, and its location in the design as specified.
Returning to the example in FIG. 1, a user could have intended the design to only allow a viewer to progress past web page 100 if appropriate data was entered in prompts 102 when button 101 is clicked. A condition placed on prompt 103 by the designer could be that the expiration date of the credit card has to be a date that is later than the current date. If the designer made a mistake while specifying the design, and specified that the expiration date had to be before the current date, the design experience would not match what was expected, and the user would be unable to progress beyond web page 100 even if all of the data in prompts 103 appeared to match the appropriate criteria. However, without a link between the design as specified and the design as rendered, the user could have a difficult time locating what portion of the specified design was causing the problem. As a specific example, a user might not be able to identify which condition was failing in the rendering of a multi-condition interaction.
The related art includes a collection of approaches that seek to provide the user with the ability to determine a link between the performance of an interactive graphical design and how the design was specified. Certain debugging tools allow a user to step through the code that underlies a graphical design as it is being executed in a run time environment. For example, in the particular situation of a web page design, the design could be rendered in an external player and the rendering experience could be paused each time a new segment of HTML was rendered by the browser so that a user could monitor the effect of each segment of the encoding on the design. Users are also able to input manual code into their designs that will output information concerning the current status of their design in combination with the execution of related events while the design is being rendered. The manual code is then manually removed from the design when it is fully debugged.
The related art also includes other methods of providing a link between the underlying design of an interactive graphical design and how that design is executed in an external player. As an example, certain analytics tools will insert code into an encoding of a design such that a notification will be generated when a particular event occurs while the design is being rendered. Referring to the specific situation of an analytics tool for a web page, a segment of JavaScript could be added to an encoded web page design that will generate a notification when a specific value is entered into a text box. As another example, logging tools can save a copy of what portion of the code was executed while a design is being rendered. As such, a user that is rendering a design, and comes across an unexpected occurrence that needs to be debugged, will be able to go back to the log and identify the portion of the code that was responsible for the unexpected occurrence.